home *** CD-ROM | disk | FTP | other *** search
/ IRIX Base Documentation 2002 November / SGI IRIX Base Documentation 2002 November.iso / usr / share / catman / p_man / cat5 / debug_group.z / debug_group
Encoding:
Text File  |  2002-10-03  |  11.3 KB  |  215 lines
  1. DEBUG_GROUP(5)                                        Last changed: 3-19-99
  2.  
  3.  
  4. NNAAMMEE
  5.      DDEEBBUUGG__ggrroouupp - Compiler options for debugging
  6.  
  7. IIMMPPLLEEMMEENNTTAATTIIOONN
  8.      IRIX systems
  9.  
  10. DDEESSCCRRIIPPTTIIOONN
  11.      This man page describes the --DDEEBBUUGG::  option to the MIPSpro compilers.
  12.      The DDEEBBUUGG option controls compiler features related to debugging; for
  13.      example, checking for compile or runtime errors, or controlling the
  14.      treatment of error messages.
  15.  
  16.      The DDEEBBUUGG options are supported by the MIPSpro 7.3 compilers for C,
  17.      C++, Fortran 77, and Fortran 90. For information about other compiler
  18.      options, see the cccc(1), CCCC(1), ff7777(1), or ff9900(1) man page.
  19.  
  20.      The following is the command line format used for the DDEEBBUUGG option:
  21.  
  22.           -DEBUG:_o_p_t_i_o_n[[==_v_a_l_u_e]][[::_o_p_t_i_o_n_2[[==_v_a_l_u_e_2]]]]......
  23.  
  24.      The _o_p_t_i_o_n is a name, which can be followed by an equal sign and a
  25.      _v_a_l_u_e.  The option names can usually be abbreviated by truncating them
  26.      to a unique prefix. Note that if new options are added, the
  27.      abbreviations may no longer be unique.
  28.  
  29.      Some _o_p_t_i_o_ns are specified with a setting that will enable or disable
  30.      the feature.  To enable a feature, specify the option alone or with
  31.      ==11, ==OONN, or ==TTRRUUEE; to disable the feature, specify the option with ==00,
  32.      ==OOFFFF, or ==FFAALLSSEE.  This man page only shows the OONN or OOFFFF settings, but
  33.      the other settings are equally valid.
  34.  
  35.      A Boolean option, if used without an optional value, defaults to OONN.
  36.      In the individual descriptions which follow, the default value that is
  37.      stated is the value if the option is not invoked at all.
  38.  
  39.    EErrrroorr DDeetteeccttiioonn aanndd RReeppoorrttiinngg
  40.      The following _o_p_t_i_o_ns are used for error detection and error
  41.      reporting. The option names ending in __cchheecckk generate runtime checking
  42.      code; those ending in __wwaarrnniinngg generate compile-time warnings only.
  43.  
  44.      ccoonnffoorrmm__cchheecckk[[==_s_e_t_t_i_n_g]]
  45.                Determines whether or not conformance checking is enabled.
  46.                When set to YYEESS, the compiler generates code to check for
  47.                conformance of Fortran 90 array operations.  Conformance
  48.                check failures generate run-time warnings unless the
  49.                environment variable FF9900__CCOONNFFOORRMM__CCHHEECCKK__AABBOORRTT is set to YYEESS.
  50.                The default is OOFFFF.
  51.  
  52.                Note that the --CC, --cchheecckk__bboouunnddss, and --DDEEBBUUGG::ssuubbssccrriipptt__cchheecckk
  53.                options all enable conformance checking.  This option is
  54.                accepted by the MIPSpro 7 Fortran 90 compiler only.
  55.  
  56.      ddiivv__cchheecckk[[==_n]]
  57.                Emit code to check all integer divides for zero divisors or
  58.                overflow, using these rules for values of _n:
  59.  
  60.                ==00   Do no checks
  61.  
  62.                ==11   Check for divide by zero
  63.  
  64.                ==22   Check for overflow (for example, IINNTT__MMAAXX--11)
  65.  
  66.                ==33   Check both divide by zero and overflow
  67.  
  68.                This option replaces --TTEENNVV::cchheecckk__ddiivv.  The default is _n==11.
  69.  
  70.      ssuubbssccrriipptt__cchheecckk[[==_s_e_t_t_i_n_g]]
  71.                Generate code to check for subscripts out of range at
  72.                runtime.  _s_e_t_t_i_n_g can be either OONN or OOFFFF.  This produces a
  73.                ttrraapp ##88 (C and C++) or an aabboorrtt (FORTRAN 77) for violations
  74.                at runtime unless --DDEEBBUUGG::vveerrbboossee__rruunnttiimmee is also specified.
  75.                The default is _s_e_t_t_i_n_g==OONN.
  76.  
  77.                This does not produce an abort for Fortran 90 or Fortran 95
  78.                programs unless the FF9900__BBOOUUNNDDSS__CCHHEECCKK__AABBOORRTT environment
  79.                variable is set to YYEESS.
  80.  
  81.      ttrraapp__uunniinniittiiaalliizzeedd[[==_s_e_t_t_i_n_g]]
  82.                Force all uninitialized stack, automatic and dynamically
  83.                allocated variables to be initialized with 00xxFFFFFFAA55AA55AA.
  84.                _s_e_t_t_i_n_g can be OONN or OOFFFF.  When this value is used as a
  85.                floating point variable, it is treated as a floating point
  86.                NaN and it causes a floating point trap.  When it is used as
  87.                a pointer, an address or segmentation violation usually
  88.                occurs.  This option replaces --ttrraappuuvv.  The default is
  89.                _s_e_t_t_i_n_g==OOFFFF.
  90.  
  91.      vvaarraarrggss__iinntteerrffaaccee__cchheecckk[[==_s_e_t_t_i_n_g]]
  92.                Emit subprogram interface descriptors for all eexxtteerrnn vvaarraarrggss
  93.                definitions (C and C++) and calls to non-prototyped routines
  94.                with actual parameters, and check the calls in the linker
  95.                and rrlldd for consistency.  The default is _s_e_t_t_i_n_g==OONN.
  96.  
  97.      vvaarraarrggss__pprroottoottyyppeess[[==_s_e_t_t_i_n_g]]
  98.                Set vvaarraarrgg prototype.  ANSI C and C++ require that vvaarraarrggss
  99.                routines be prototyped, and the compiler assumes this by
  100.                default.  Failure to provide prototypes for calls to such
  101.                routines with floating point arguments usually causes
  102.                failures.  Turning _s_e_t_t_i_n_g to OOFFFF eliminates these failures
  103.                at some cost in program performance.  The compiler and/or
  104.                linker usually produces warnings for programs which might
  105.                encounter this problem to assist in fixing the problems.
  106.                The default is _s_e_t_t_i_n_g==OONN.
  107.  
  108.      vveerrbboossee__rruunnttiimmee[[==_s_e_t_t_i_n_g]]
  109.                Modify the behavior of various runtime checks to report
  110.                source routine and line number of failures instead of just
  111.                reporting trapping. This increases the code size impact of
  112.                checking, but provides better information.  The default is
  113.                _s_e_t_t_i_n_g==OOFFFF.
  114.  
  115.    MMeessssaaggee ccoonnttrrooll ooppttiioonnss
  116.      Messages are classified as follows:
  117.  
  118.      * _d_i_s_c_r_e_t_i_o_n_a_r_y _e_r_r_o_r_s, which can be turned off
  119.  
  120.      * _e_r_r_o_r_s, for problems which cause the compilation to fail
  121.  
  122.      * _w_a_r_n_i_n_g_s, for situations which are likely to be programmer errors
  123.  
  124.      * _r_e_m_a_r_k_s, for situations which might be problems
  125.  
  126.      By default, the compiler prints error and warning messages, but not
  127.      remarks.  Most compiler messages have an identifying number (the
  128.      _m_e_s_s_a_g_e _I_D), which is printed in parentheses after the classification;
  129.      this message ID number can be used in the options described here.
  130.  
  131.      Most error messages cannot be controlled; they are emitted, and the
  132.      compiler rejects the file being compiled.
  133.  
  134.      The following _o_p_t_i_o_ns are used for message control.
  135.  
  136.      eerrrroorr==_I_D_1[[,,_I_D_2,,......]]
  137.                Treat the problems reported by warnings or remarks with
  138.                message IDs _I_D_1, _I_D_2, etc., as errors.
  139.  
  140.      ffuullllwwaarrnn[[==_s_e_t_t_i_n_g]]
  141.                Emit all informational messages, including remarks.  _s_e_t_t_i_n_g
  142.                can be OONN or OOFFFF.  The default is OOFFFF.
  143.  
  144.      rreemmaarrkk==_I_D_1[[,,_I_D_2,,......]]
  145.                Treat the problems with message IDs _I_D_1, _I_D_2, etc., as
  146.                remarks (that is, do not print them unless
  147.                --DDEEBBUUGG::ffuullllwwaarrnn==OONN.  This option is not accepted by the
  148.                MIPSpro 7 Fortran 90 compiler.
  149.  
  150.      ssuupppprreessss==_I_D_1[[,,_I_D_2,,......]]
  151.                Suppress the messages with IDs _I_D_1, _I_D_2, etc. This has the
  152.                same effect as --DDEEBBUUGG::wwooffff==.
  153.  
  154.      wwaarrnniinngg==_I_D_1[[,,_I_D_2,,......]]
  155.                Treat the problems with message IDs _I_D_1, _D_2, etc., as
  156.                warnings.
  157.  
  158.      wwooffff==_I_D_1[[,,_I_D_2,,......]]
  159.                Turn off the messages with IDs _I_D_1, _I_D_2,...  Has the same
  160.                effect as --DDEEBBUUGG::ssuupppprreessss==.
  161.  
  162.    RRuunnttiimmee EErrrroorr RReeppoorrttiinngg
  163.      Many of the --DDEEBBUUGG options support the detection of errors at runtime.
  164.      For example, --DDEEBBUUGG::ssuubbssccrriipptt__cchheecckk can "report" the errors either
  165.      with a simple trap which doesn't require much code, or with a more
  166.      expensive library call which identifies the offending routine and line
  167.      number.  The latter choice is enabled by the --DDEEBBUUGG::vveerrbboossee__rruunnttiimmee
  168.      option.
  169.  
  170.      The reporting routine is named ____CC__rruunnttiimmee__eerrrroorr.  Setting a debugger
  171.      breakpoint at this routine is a good way to obtain further information
  172.      about the runtime errors it reports.  However, ____CC__rruunnttiimmee__eerrrroorr is
  173.      not available in lliibbcc..ssoo in versions of Irix prior to 6.5.  A core
  174.      dump with memory failure may occur in C or C++ programs run under
  175.      pre-IRIX 6.5 OS versions, if the programs are compiled with
  176.      --DDEEBBUUGG::ssuubbssccrriipptt__cchheecckk::vveerrbboossee__rruunnttiimmee and they encounter a subscript
  177.      range violation.  In these cases, the programs will dump core with a
  178.      memory failure instead of reporting the error location.
  179.  
  180.      If you provide your own dummy ____CC__rruunnttiimmee__eerrrroorr, you can set a
  181.      debugger breakpoint at it to locate errors.  Furthermore, you can
  182.      obtain a location report for this purpose by providing a routine
  183.      similar to this example:
  184.  
  185.      ========================================================
  186.      #include <signal.h>
  187.      #include <stdio.h>
  188.  
  189.      void __C_runtime_error ( int trap_code, char *name, int line_no, ... )
  190.      {
  191.        switch ( trap_code ) {
  192.          /* Subscript range violations: */
  193.          case BRK_RANGE:
  194.            fprintf ( stderr, "error: Subscript range violation", name);
  195.            break;
  196.  
  197.          /* Others (unknown trap codes): */
  198.          default:
  199.            fprintf ( stderr, "error: Trap %d ", trap_code );
  200.            break;
  201.        }
  202.  
  203.        fprintf ( stderr, " in '%s'", name);
  204.        if ( line_no != -1 )
  205.          fprintf ( stderr, " (line %d)", line_no );
  206.        fprintf ( stderr, "0 );
  207.        exit (99);
  208.      }
  209.      ========================================================
  210.  
  211. SSEEEE AALLSSOO
  212.      cccc(1), CCCC(1), ff7777(1), ff9900(1)
  213.  
  214.      This man page is available only online.
  215.